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<5?) Abstract 

A first electronic representation of ;j financial inMrumem (Kit i.ttivifnyhvg with a 
rspre>"-it.s!.of. s co- verted to a j-ff ' (i<-itver> format complying with a second prow 
ovci an electronic data commtmteation iwtwotk ;S2}. This enable* itrfoniiiition roneema 
tielwoA in a predetermined tram.:!. Tlie iwe ntion may ix generally appiiecl to a ftnariei 



■d ufnoco. created (K^ The rrJ ei^troi 
C74). The digital delivery format is delivered 
(he financial instrument to be delivered ovt 
itiAtrcment such as a check (20). 
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of electronic: funds 

As seen in Fig. 1, payment of a f 
instrument 10 is normally effected when a f 
institution .;.:: presents the instrument tc a 
10 banking institution 14, The second 




the first banking institution, 
instruments arncr.c banking mstxtuti 
intermediate steps., such as routing the 
If, through a clearing house 1£ , 

When the instrument is a wntter 
as in Fig. 2, a payer 22 presents the check to a 



: of the payee 2 6 . 
29, the date 3 0 

of the 



s) . The check indicates the 
an amount payable 28, a courtesy artv 
the check was created, the printed : 
the. name of the payer's bank 34, the number cf the 
run:: 36 at the payer's bank., the payer's 
i, check routing inr ormat ion 4 0 . and a MICR 
line 3« which is a magnetic coding of some of this 
information, Essentially, the check directs the payer' 
bank to remove the indicated amount 28 from the payer's 



30 The payee places his signature 42 on the back of 

the check and deposits the check with the payee's bank 4- 
with an instruction that payment be made to his account 
46. The check is then routed to the payer' s bank 3 4 
through a clearing house 18, a federal reserve bank or 

3-* otner established els: .Tiring arrangement. Thic procedure 
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tor er fectuating payment between banks ss known as 
forward check presentment. 

The payer's bank verifies the- authenticity or the 
check and tat least for soma checks "< the siqnaturss 3 8 of 
5 the payer. If the check is authentic and the payer has 
sufficient funds in his account 35 to cover the amour: t ol 
the check 2S, tne payer's bank debits r.he payer's sccaurr 
and transfers funds to the payee's bank in the amount 
designated on the check as payment 26. 

10 A check typical J y is considered authentic if ir, 

contains the signature 3B of the payer, the printed 
identification of the payer 32 and r.he printed nat-ie of 
the payer's bank 3-;. and do'HS net appear to be altered. 
It the check looks authentic, the payee's bank 

15 provisionally credits the payee's account 46 fox the. 
amount designated on the face of the check 2 8 pending 
clearance, and acceptance and payment by the payer's 
bank. Tne payee's bank credits the payee's account when 
the payee's bank receives payment from the payer' <? bank _ 

2-0 This procedure is known as check posting. 

A complete check transaction thus includes 
verification steps performed by the payer's and payee's 
banks 34 and 44, Processing a paper check requires uime 
as the physical check is routed from the payer, to the 

25 payee., then to a clearing house , federal reserve bank or 
the payee's bank directly, and finally to the payer's 
bank. The same is true of other types of financial 
transactions involving paper instruments, such as credit 
card slips generated during a credit card sale. In a 

30 credit card transaction, a merchant makes an impression 
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exception processing provides for dealing with a prooiero 

m the normal flow of a check through the system, the 
physical check itself may need to be seen, m order to 
resolve the problem. In this case,, the paper check is 
routed back to the payee's bank or rhe bank of first 
deposit . 

several mechanisms for using electronic 
communication to substitute for paper flow in financial 
transactions are in use or have been proposed. In 
particular, electronic presentment: of checks is a 
meeharusr. used to aid m clearing checks collected by 
banks prior to or without routing the physical checks. 
Electron; c Data interchange {EDI) is an electronic 
transactional system in which funds are frequently 
transferred over existing financial networks. 

Cnsck imaging is an electronic transaction 
procedure involving the scanning of a paper check by a 
scanner. The scanner digitizes the image of the check 
pixel by pixel and stores the image electronical 1 y in a 
memory. The image may then be transferred electronically 
to substitute for or precede the physical delivery of the 
check, i.e. to truncate the clearing process. The image 
of the check also may be recreated on a computer monitor 
or on paper for verification by the appropriate banking 
institution. 

Each bank may have its own system for capturing 
check images. A critical eiemenc of the interchange of 
check images is the ability to determine where and how an 
itsiactfe can be obtained whenever it is needed. 

i Summary 

in general, in one aspect, the invention features 
a computer -based method in which a first electronic 
representation of a financial instrument complying with a 
first protocol is created. The first electronic 

> representation is converted to a digital delivery format 
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igical delivery 



complying with a second protocc 

fonr.au is delivered over an el 

network. This enables information 

financial instrument to be de3 i 

Implementations of the invention may aiso incL 
one or more of the following features. The digital 
delivery format may be converted to a second electron! 
representation complying with a third protocol. The 
10 tnird protocol may be t.ne same as the first protocol. 

electronic representation may also foe 



or printing sr. in 



image of the financial inrtx 
the financial instrument. 

The first electronic 
at a first financial institution and the digi 
format delivered to a second financial institution 
this appiicatioi 
institution w e v. 

second protocol may be a protocol recognised in 
the first financial mstituti 

institution. The first protocol m-isy also include <■ 
proprietary protocol of. tne first financial mstit.; 

The second protocol may include a commonly 



2 5 

The first electronic representation may include 
image of the financial instrument or a digital code I me 
representation of the financial instrument. 

The financial instrument may be a check or a 

3 0 credit card slip. 

The first electronic representation may t-e store 
fox subsequent retrieval upon a request. The first 
electronic representation may be stored at a first 
financial institution. The request ro«y be delivered 
35 electronically to the first financial institution from a 
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second financial institution and the digital delivery 
format delivered to the second financial institution. 
The first electronic representation may foe processed at 
the first financial institution. The processing may 
5 include displaying an image or the financial instrument 
or printing an image of the financial instrument . The. 
request: may foe generated automatically. The first 
electronic representation may be assigned an 
identification index. The request may include the 
10 identification index. 

The digital delivery formal: may foe encrypted for 
secure delivery over the electronic data communication 
network . 

In general , in another aspect, the invention 
I ? features apparatus including a capture device for 
obtaining a first electronic representation of a 
financial instrument complying with a first protocol, a 
translator for converting the first electronic 
representation into a digital delivery format complying 

2 0 with a second protocol, and means for delivering r.he 

digital delivery format over an electronic data 
cotnmunicat i on rie c work . 

Implementations of: the instrument may include one 
or more of the following features. The first electronic 
25 representation may include an image of the financial 
instrument or a digital code line representation of the 
financial instrument. The financial instrument may be a 
check or a credit card slip. The second protocol may be 
a commonly accepted protocol . The capture device may 

3 0 include a scanner. The translator may include an EDI 

translator . 

A memory may be included to store the first 
electronic representation. A workstation may be included 
for processing the stored first electronic 
3'v. representation. The processing may .-.nclnde displaying an 
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image of the financial instrument or printing an .Image of 
the financial instrument . The workstation may include an 
interactive display of the first, electronic 
represent at ion . 
5 In genera], in another aspect, the invention 

features apparatus including means for electronically 
receiving a digital delivery format of a financial 
instrument complying with a first: protocol, and a 
translator for converting the. digital delivery format 
10 into an electronic representation complying witn a second 
protocol. 

Imp lemsntat ions of the invention may include one 
or more of the following feature:!;. The electronic 
representation may include an image of the financial 
15 instrument or a digital code! me representation of the 
financial instrument. The financial instrument may be a 
check or a credit card slip. The first protocol may 
include a commonly accepted protocol. The translator may 

30 A workstation may be used to process the second 

electronic representation. The processing may include 
displaying an image of the financial instrument or 
printing an image of the .financial instrument: . The 
workstation may include an interactive display of the 

25 first electronic representation. 

In general, in another aspect, the invention 
features a method for truncating a paper check in a check 
clearance system by capturing an electronic image of the 
paper check at a first banking institution, the 

3.0 electronic image complying with a first protocol, 

converting the electronic image to a digital delivery 
format complying with a common second protocol, sendmq 
the digital delivery format digitally from the first 
banking institution to a second banking .institution, at 

35 the second banking converting the digital delivery format 
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to an electronic image complying with a third protocol, 
and processing the electronic image complying with the 
third protocol for clearance purposes. 

Implement at ions of the invention may include the 
5 following feature. The digital delivery format may 
.include a secure format created by encryption. 

In general, m another aspect, the invention 
features a method for use by i i as tic ). a I. institutions with 
respect to financial instruntencs including storm?, at 

10 different financial institutions, electronic images of 
paper t manciai instruments presented to the respective 
institutions, the storing at dif ferenr tinaneial 
institutions being done in accordance w:;th different 
protocols, at each of the financial institutions, 

3.5 accepting electronic requests for copies of specified 
ones of the electronic images stored at the respective 
financial institutions, the requests being sent by any of 
the financial institutions via a common cotnmum cat ion 
network, and at each o£ the financial institutions, 

1:0 responding to electronic requests by converting the 
requested electronic images; to a common prot.oro} and 
returning the Image:" In digital form to the requesting 
financial inst itut ion . 

Implementations of the invent .ioa may .include the 

25 following feature. The electronic requests may be 

The invention relates to the communication of 
binary content images of funds transfer instruments 
between banks. Each bank wraps the binary content in the 
3 0 bank's own proprietary format. A transmitting bank, 
packages the proprietary format containing the binary 
content within a standard message format . The receiving 
ban It uses the elements of the standard message forma;: to 
find and interpret the binary content for use or display. 
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Advantages of the invention nay include one or 
mo re o f t h e f o 1 1 ow i rig . 

Many business functions could benaf.it from check 
image interchange, including signature verification and 
5 stop payment orders and/or payer information. The 
interchange of images in addition to the electronic 
interchange of check cods line data allows truncation to 
be possible. 

The invention addresses the problem of check image 
10 interchange without physically exchanging paper checks. 
The invention provides an electronic conwnunrcat i on 
alternative for check image transfer. 

The invention enhances the e.i ect tonic presentment 
of checks with the addition of check images. Critical 
15 business flows are rearranged and altered. The invention 
also provides a new way to implement check pr ocessinq to 
truncate the flow of paper checks. its addition, the 
invention provides a system for locating check images 
among the IS, 000 banking institutions in the United 
20 States. Check images may be transported routinely or on 
demand . 

The invention provides integration of existing 
banking systems to facilitate check processing. The 
existence of these systems will allow for implementation 

25 and acceptance by the banking industry. 

Trie invention to a degree electronically mimics 
heavily- used and wel i. - understood existing paper check 
processes to enable it to be readily accepted by -;he 
banking industry. By retaining the basic characteristics. 

30 and flexibility of, e.g.., the paper check, the invention 
may be adopted more rapidly. Due to the similarity with 
exchanging paper checks, the .invention can be used within 
the structure of existing laws, regulations, and standard 
bank i ng p ract i ce s . 
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Since the system can be fully .automated f and n< 
processing can be done outside of existing application 
the cost of electronic check image interchange may tie- 
lower, and the costs of implementation minimized. To 
further minimize implementation costs, check image 
interchange may be integrated with the existing bank in 
infrastructure, including some of the mechanisms 
currently used, such electronic presentation of checks 
The use of electronic check image interchange \ 
he more cost effective than existing paper ctieeks due 
volume efficiencies and the automatic processing 
capabilities of computers. The use; of electronic 
transmission is less costly than physically transport:.! 
paper. Banks may significantly reduce the costs of 
mailing and/or transporting paper checks, such as for 
envelopes, stamps, and incremental labor. 

Other advantages and features of the. invention 
will become apparent from line foli owing description an 
from the claims. 

Description 

Figure 1 is a block diagram of a financial 
transaction . 

Figure 2 is a flow diagram of the s;:eps of a ci 
t: ransact ion • 

Figure 3 is a block diagram of a network of 
f inanoi al inst i tut. ions , 

Figure 4 is a block diagram of a bank's cneck 
image interchange system. 

Figure B is a flow diagram of a cneck present me 
application. 

Figure 6 is a flow diagram of a chock query 
appl i cation , 

Figure 7 is a block diagram of a check image 
i at ercha nge system . 
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Figure 8 is block diagram of. the functional group; 
of the ANSI X9.4 6 proposed standard. 

Figure 9 is a b.lock diagram of a data structure 

scheme . 

As seen in Fig. 9, the invent ion provides an 
instrument image interchange facility 500, At one 
institution 493, a paper instrument 501 is scanned and 
stored using a conventional data structure 503 to canctire 
the binary image content S04. Typical such structures 
includ'2 JPEG, CCITT Group IV, and IBM's ABIC. The 
instrument image interchange would require that the 
binary content of the image be kept in one of these 
I or mats or some other preapproved form. It also requires 
that the binary content be encapsulated (i.e., packaged 
or enveloped) in a preapproved common data structure 506, 
for example one complying with ANSI proposed standard 
X,9, If. both of these requirements are met then the 
packaged data structure may be sent via any communication 
mode to any other institution which can then reliably 
recover and use the binary content of the instrument: 
image by means of a readily aval i able, easily defined 
algorithm. The data structure may also enclose 
information 510 from proprietary data structures 
associated with the binary content so long as it also 
includes the standard forms of data structure 
information. 

In current schemes it is common for an uistituticr 
to envelope binary content in a proprietary envelope tor 
various purposes, such as the IOCA scheme of IBM. The 
invention does not prevent continued use of such 
arrangements at: each institution nor the inclusion of 
proprietary data structure information in what is sent 
between institutions, but it provides an alternative 
approach that permits fluid interchange of image content 
anywhere in the world via a wide variety of communication 
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media arid among a wide variety of ins t a tut ions for a wide 
variety of purposes without, any two of the institutions 
having v.o engage in special negotiations r.o achieve the 
result . Each institution is able to rely or. the common 
structures as assuring its ability to participate in the 
syst era . 

Ay shown .m Fig. 3, banking institutions 50 may 
interchange check images via a network ?2, such as a 
distributed TCP/ IT based network. A TCP/IP network could 
utilise dial-up ISDN, for example . Electronic networks 
include the dial-up, Internet, wireless, and e-mail 
networks . Since security is critical for communication 
ot electronic funds transfer instruments, established 
banking networks, which are secure and well disciplined, 
may be preferred to public networks . 

Each banking institution is a node on the network 
52 and has a server S4 (e.g., a UNIX server), a local 
image store 56 and a workstation 58 such as « personal 
computer with a monitor. Through the network, any one of 
these components in one bank may communicate with any 
other component in a bank connected to tne network, 
whether or nor. the components are at the same location or 
geog raph i c a 1 1 y s eparat ed . 

In Fig. 4, bank 50 has an image capture system 62 

5 connected to its server. The bank which captures a check 
image is known as the bank of first image. The image 
capture syscem includes a scanner 64 for obtaining an 
electronic digital image of both sides ot a check and for 
deriving code line data from the check such as the payee, 

) the payer, the payer's bank, the payer's bank account and 
the amount to be paid. The check may also include an 
imprint of a unique identifier for the check such as a 2D 
bar code which would allow tracking of the check by 
analyzing its image. The image capture system 62 may be 

5 a known proprietary system chosen by the bank, such as 
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the High Speed Image Item Processing System available 
from Unisys, The codelin* data tray be converted to an 
format for electronic presentment of checks by a 
processing system 66, which may be connected to the 
5 bank's server. 

The digital check image and the code line data are 
atored m a data store 56 known as an archive. The bank 
may transmit both the codeime data from the check and 
the check image data over the same network, although the 

10 codeime data and the check image need not be transmitted 
together. The archive 56 stores the data in a 
proprietary format chosen by the bank, such as the ,'imaqe 
Object Content Architecture (I OCA) format of IBM or the 
Tag Image File format {TIFF} used by Unisys. 

15 Check image interchange involves a set. of 

applications which provide user interfaces tor. banks to 
request check images from other remote banks, receive 
images from other remote banks, and provide images to 
other banks upon request. Two check image interchange 

20 applications concern forward check presentment and image 
queries. The applications manage the resources required 
to process the queries, responses and acknowledgements 
associated with check image interchange. 

The .bank 50 has at least one workstation BB for 

25 formulating and managing image queries to remote banks 
and for viewing retrieved check images fay an operator. 
The bank may also support other app.) i cat ions "?5, 
including its own use of the stored check imaqes and 
codeiine data such as tor processing and viewing. 

30 In an alternative embodiment: , check images and 

data may be captured and stored by a third party 
repository 57. The repository would provide an archive 
server 5.9 for access to the stored check images and data 
by other banking institutions. 
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The applications muss: support communication of 
check: linages and requests in a standard jrorrnat since each 
bank employs its own chosen proprietary image capture and. 
storage systems . The communications standard chosen for 
check image interchange is the ANSI 559.46 proposed 
standard. The mechanisms for r cueing check images and 
requests between banks and for searching for images 
utilize the X9.4 6 proposed standard for the entire 
interchange process . Although forward presentment of 
codelme data alone may be performed either with a 
commercially available product for electronic presentment 
of checks or using the X9.46 proposed standard, use of 
the X9.4 6 proposed standard will be assumed Sor present, 
purposes . Details of the X9 . 4 <S proposed standara ax& set 
forth in the ANSI X9.4<5 Data Structure Reference, 
available from the X9ts working group within ANSI and 
incorporated by reference. 

A system known as Image Locator Services {ILS} 72 
.located in the bank as part of its server processes check 
imag* data., code J me data and query requests from the 
bank's proprietary format: into the. X9.4S proposed 
standard format tor communication with other banks. A 
commercially available EDI translator 74 within the ILS 
may be used to perform the translation. The ILS 
determines where data is to be routed in the interbank 
exchange environment and provides the communications 
mechanisms needed to transmit information in the standard 
norma t . The check image interchange applications include 
m format ion required to build the content of XS.4C query, 
image and acknowledgement messages and transmit them to 
and. receive then; from the EDI translator "4 via an 
a pp i i c a 1 1 on i n t e r face. 

As shown m Fig. 5, in forward check presentment 
100, check images and codelme data are captured (step 
i02> using the bank's existing proprietary capture 
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equipment , The captured data is placed in an image 
archive in the bank's proprietary format (step 104>. 

After capture, the code line data J rotn the checks 
must foe packaged and gent to the payer's bank to .initiate 
5 payment procedures. A code line data file is created 

(step 106} which includes information for requesting the 
corresponding check images and the code 1 in* data from 
which images to be viewed can be identified. For 
example , the codel m« data file contains an i^age 

10 identifier corresponding to the stored check .image. The 
codel ine data is then sent to the XLS (step .108.;. 

The ILS translates the codeline data file to the 
X9.4S proposed standard format and bundles .it into an 
XS.46 data tile -step 110; . The translation process maps 

15 the file into an XS.46 data stream to send to the paver's 
hank. The codeline data tray be sent by itself, or with 
the corresponding check image or portions of check imaae . 
Or, as described below, the check inage data may be 
t ransmi t. ted by i t sel f. . 

20 The ILS also determines the recipient of the 

translated codeline data {step 112!. Thus, the 
information sent to the ILS must contain enough 
information to identify the receiving institution. The 
XLS then determines the details tor r. ransnutt ing the 

25 translated file to the recipient bank, including the 

phone number to dial, the network address, and/or the e~ 
mail address. 

The ILS executes the transmission to the recipient 
bank (step 114), and the recipient bank's ILS receives 

30 the transmission of the codeline data in the XS.46 
proposed standard format [step 115; . 

Trie recipient bank's ILS determines the nature of: 
the K9.4Z data stream it has received (step 118) and 
identifies which internal system is to receive the 

35 codeline data. Knowing this information, the ILS 
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translates? the eodel ine data into a rormat. usable by the 
internal system of the recipient bank {step .120) . 

The XLS interfaces the translated code line data 
file with the appropriate, system for processing (steps 
5 .122 and 124). Although each bank may treat the codeline 
data differently, the code line data ultimately is passed 
on to the appropriate internal posting system to complete 
p-ayment of the check. However, at this time, not all 
banks post checks with electronic presentment of checks. 

10 Thus, the result, of the check presentment procedure is 

the identification of images; that the recipient bank must 
request . Usually this is done to research probl ess items 
that cannot be posted directly from the code! me data fox 
various reason?.:. Also, research may need to be done to 

15 handle other exception conditions such as stop payment 
orders, ncn-suf f icient fends, closed accounts, etc. The 
result of the check posting procedure -nay be a report of 
check images to oe examined or a list of items to be used 
in an. aut.oma.ted query . 

2 0 In Fig. 6, in the check query application 130, two 

strategies roay be employed to accomplish a query. For a 
single it ere real time query {step 132), the operator 
enters the image identifier of the desired check image. 
The query for images to be viewed may also be 

25 formulated in advance and stored in a pick list: to be 
batch processed {step 134; . For example, the exception 
processes may generate the pick, list, or the operator may 
enter the image identifiers from a report. Received 
images may then be stored locally for off-line viewing. 

30 If the exception processes automatically generate the 
query, then the query can be carried out without any 
action by the operator, and the images would be ready for 
viewing when the operator is available. 

The processes generating the queries send the 

3:5 query request m the bank's proprietary format to the XLS 
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a dent i fy the requesting ban;:. The ILS then attends to 
the details for transmitting the lile to the. request ing 
bank, including the phone number to dial , the network 
address, and/ or the e-mail address. The I LB executes the 
5 transmission of the XS.46 file to the requesting bank's 
ILS (step 160} . 

When the ILS of the requesting .bank receives the 
transmitted query response (step 162; , it determines the 
nature of the X9.46 data stream it has received {step 

1C 164) and identifies which internal system should receive 
the query response data. The ILS translates the query 
response into a format usable by the internal system 
;e,g., the workstation) {step 166). The workstation at 
the requesting bank displays the received images (step 

lb 166) . or the linages and data received are stored for 
later inspection (step 170} , 

Applications for check image interchange have been 
developed by IBM and Unisys. The check image interchange 
components are provided on hardware and software 

20 pi sr. forms such as RISC/6000 for the IBM AIX system and 
UGCOC for the Unisys UNIX system, as well as platforms 
for the EDI translator. Connection to the network may oe 
accorapl i shed through network boxes such as an Adtran 12 B 
DSU modem for ISDN connectivity and Cisco 2502 access 

25 routers for LAN connectivity to ISDN equipment: . These 

have been used in pilot experiments. Any scheme that can 
establish a TCP/IP network may be used. 

The image capture system captures both the 
electronic digital images and the code! ire data for 

!s0 checks. The scanners that may be used range from high 
speed reader/sorters such as those available from Unisys, 
AT&T and IBM, to low speed desktop scanners such as those 
available from Hewlett - Packard. In some system:-:;, the 
code line information is entered ny the operator rather 
than through the scanning operation. 
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The ire-age capture system exports the captured 
information to the archive and generates index 
information used for identification. The index 
information ideally includes the item sequence number, 
S the cycle indicator (day of the week; , the processing 
data, and the initial storage device number. For 
convenience, export of information also should be 
controllable by other useful selection criteria such as 
sorter job. If the image capture system doer, not perform 
10 these functions; it. must allow the archive system to 

access the information so that the dots can be stored and 
indexed. Alternatively, the capture system may be 
integrated into the archive system for ease of storage 
and indexing 

IS The number of views presented to the requesting 

bank for each request corresponds to the number of views 
captured by the bank of first image's image capture 
system. Check image interchange may support varied image 
views , such as front black- white , front gray scale, back: 

20 black -white and back gray scale. 

Storage and communication of. check, images is 
carried out m the compressed image format, of the bank of; 
first image. The image data compression; algorithm used 
is determined by the binary image format of the hank, of 

25 first image. Image data may be formatted using accepted 
compression algorithms, which include Adaptive Bi level 
Tmage Compression (ABIC) by IBM, and CCITT Group 4 and 
the Joint Photographic Kxpert.s Group iJ'FEG) used by 
Unisys and AT&T. No image dac« conversion takes place 

30 prior to or during communications, and the receiving 
system converts the image as needed or desired. 

The use of electronic presentment of: checks allows 
check data to he interchanged ixi real time and at volumes 
that current technology, price and performance can 

35 accommodate. By sending tne data in code line data format 
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(which may also contain an .identification lato&l of the 
associated image) , the receiving hank can process the 
data, post the check, and be assured of resolving 
discrepancies with the data and handling exception 
5 conditions in a timely manner by access inq the check 
image frorc the bank of first, image. In some cases, the 
actual check images will be forward presented, such as 
for items net qualified for processing of electronic 
presentment of checks or where the condition of the check 

10 would dictate a need by the recipient lor the image. The 
receiving bank can resolve the problem causing the 
exception by viewing the image and making the necessary 
repairs to tine data... 

The components of the ILS are constructed on a 

15 server, such as a UNIX -based server. The software 
components required to implement image capture and 
transfer through the ILS include the applications and the 
EDI translator. These software components enclose and 
optionally encrypt, perform hashing on, and provide a 

2 0 diair.ai signature (if one does not already exist ) for the 
compressed image in a ANSI X3.46 proposed standard 
envelope that identifies the image format and contains 
various pieces of data pertinent to the image., such as 
the. index information. A digital signature may already 

23 exist prior to the processing,- if so, the digital 

signature is simply passed through. Tne t.Dl translator 
maintains communication session control between the banks 
exchanging data in X9.46 proposed standard format. 

The EDI translator in the ILS constructs Xi-,46 

30 messages based on mformaticn received trom the 

processing system, the archive and the workstation, and 
passes information received in X9-46 proposed standard 
format, to these systems. Data is passed between the EDK 
translator and the other systems using an application 
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interlace, which may include sockets, named pipes, Files, 
FTP, e-mail or other means . 

Image data, for example, is provided to the EDI 
translator in TIFF, I OCA or. another image encapsulation 
5 data structure via the application interlace. The EDI 
translator opens the image content: and constructs the 

interchange object based on the control data and 
the image binary data contained m the image object. 
Conversely, che EDI translator assembles image data 
10 received in an X9.46 data stream into TIFF or I OCA image 
objects as specified by the receiving bank's application. 
The archive provides a repository of check i mages 
and code! me data. The archive includes all the 
processing data elements necessary to locate imaqes and 
15 ccdeiine data from queries made to the system, including 
the it era sequence number, processing date, cycle number, 
and device identification. Other financial data storage 
requirements may include the MICR 3 me of. the check, the 
bank, of first deposit and document, image number, the date 
20 the check, was paid, and the disposition of the check. 
The images of the front and back of the check may be 
stored in their original capture format or .in an export 
format tnat includes the data compression and an image 
wrappe r . 

2- The archive interfaces with tne ILS to perform the 

query function. The archive normally will be used both 
for check image interchange and for check processing such 
as normal proof of deposit operations. Alternatively, 
there may be a separate archive used solely for 

3 0 interchange or other functions. 

The archive system must be capable of receiving or 
i sporting images and data trom the capture system. This 
exchange may be via seamless integration or a data export 
type of interface. The process of storing may occur in 

35 real time during capture, or in some case? it may be a 
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separate expert process that take,-? place subsequent to 
capture. Further, some aspects of data integrity and 
security may be implemented within the archive system. 

The workstation provides a user interface for 
querying and displaying images. Trie workstation may 
support the entry of an image identifier for querj.es as 
we'll as imbedding the query functions into the various 
business applications that, utilize check images, such «s 
exception processing and signature verification. Upon 
entry of user data needed to formulate a query, the 
formatting routiaes of the workstation's software 
establish a query transaction to be transmitted to the 
XLS, Examples of workstation plat fenny are Windows and 
OS/2 Warp. 

The. images returned to the workstation from the 
ILS after a query request are in the da i: « format used by 
the bank of first image. No transcoding is done by the 
bank of first image. Thus, the display system of the 
workstation must foe able to understand a! 1 of the 
accepted standard image formats. The works;: si; ion has 
software to decompress and decode received image formats, 
such as image Viewer. 

Additional del:::: lis of the check imaging system are 
shown in Fig, 7, 

As shown in Fig. 8, the ANSI X9.4 6 proposed 
standard 200 defines several functional groups for 
exchanging image information and coded data. 

The query request functional group 2 02 is used by 
the requesting bank to request one or more images from 
the bank of first image. Each query contains a unique 
query ID 204 for maintaining continuity between the 
original query, acknowl edgmenfc and the transmission of 
images to the requesting bank. 

The query request functional group 202 permits an 
image to be specified individually, based on its image 
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identifier, or to be specified based upon generalized 
search criteria such as account number and serial number 
range. The requesting bank also may request check image 
formats chat conform to its viewing software. Additional 
5 query request elements may include snippets of the check 
image, scaling and color. 

The items views functional group 206 is used to 
return image items requested by the requesting bank. 
This functional group supports transmission cf one or 

10 more images. item data loop structures 206 contain the 
information for imaged items. Multiple icem data "loops, 
each represent inq a single image, may exist within the 
functional group. Within each item data loop, one or. 
more item view loops may exist rc represent different 

15 views of the image. Therefore, a single transmission of 
an item views functional group may contain multiple 
images, each of" which may further contain multiple views. 
The views available to be sent to the requesting bank, 
depend upon which views were captured by the bank of 

20 first, image. 

The financial data functional group 210 is used to 
convey check code I ins and other associated financial 
data. 

The application acknowledgment functional group 
25 212 provides a positive or negative application 

acknowledgment 21-1 that the content of the information 
received in an exchange is .functionally correct and 
acceptable to the recipient. An application 
acknowledgment 234 may be requested in response to the 
30 transmission of a query request functional group 202, an 
item views functional group 206 or a financial data 
t uric 1 1 on a 1 group 2 1 0 . 

The functional acknowledgment functional group 2i<? 
provides a positive or negative functional acknowledgment 
35 218 that the information received l.r an interchange is 
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syntactically correct for a tunct ional group, nransaction 
set, or data segment , A functional acknowledgment 218 
may be requested in response t o the transmission of a 
query request, functional group 202 . an mom views 
\: f-anctional group 20S or a financial data functional group 
2.10. Unlike the other f unctional group.?, the information 
in cbe f unct lonaJ acknowl edgaient functional group xs 
supplied entirely by the EDI translator in response to 
the information received in tne context of the functional 

10 group which invoked it; no input from the receiving 

application is required. The EDI translator constructs 
the t unet. ionai acknowledgment functional group and 
transmits the response back to the requestor without: the 
i n tervent i on o f t he app 1 .1 cai t ion . 

15 The X9.46 proposed standard also supports other 

image capture and transfer functions. The query request 
functional group 2 02 and the item views functional group 
206 provide a security header which allows 
authentication , encryption services, and digital 

2 0 signatures to be applied to transmission of these groups. 

The Y.9.4& proposed standard also permits one or more 
transaction sscs to be specified for each functional 
group. Additional functional groups and data elements 
may be added at a later date to support an expanded 
25 implementation of the X9.4 6 proposed standard. 

The EDI translator accepts source images in either 
the I OCA or TIFF object format, for example, and builds 
X9.46 interchange messages which are independent of the 
proprietary systems employed by the bank and which 

3 0 contain the appropriate control and data content, but do 

not rely upon tne syntax of the original image data. Trie 
receiving bank may request that the translator 
reconstruct the image into its original object, format , it 
it is known, or reconstruct: the image, object into a 
35 represent at ion chosen by the bank. For example, the 
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sending bank may have provided the image as a TIFF obi eel: 
but the receiving bank, may wish to recons*. ruct the image 
as an I OCA object. 

Under normal circumstances it is assumed that the 
S receiving bank will select a single represent at ion for 
all itnage is it receives, and that the representation will 
be defined in the translator via a configuration table. 
It is also conceivable; that the receiving bank may wish 
to dynamically define the .tor mat of the images it 
10 receives based on the source of. the images. The format 
chosen by the bank will be incorporated into the EDI 
translator . 

The transaction is the basic unit of communicat ion 
with the EDI translator. Each transaction contains the 

15 information necessary to represent the content: of an 
X9.46 functional group. The EDI translator uses the 
content, of the transaction to construct, an XS.46 
functional group for outbound transmissions. For inbound 
transmissions, the EDI translator constructs a 

20 transaction from the received X9.4 6 functional group. 
The interface with the EDI translator includes pre- 
defined interface: files. 

Each X9.46 functional group has a pair of 
dedicated interface files for outbound transactions to 

2.5 the EDI translator and inbound transactions from the EDI 
translator. For example., each interface file has a 
record length of 80 bytes followed by a line feed 
character. Each record within a file represents a 
logicisi grouping of data elements, referred to as 

3 0 segments. A segment, consists of a segment identifier and 
the data elements, whicr. may not exceed 8 0 bytes;. The 
segment and data element structure of the outbound and 
inbound interface files is the same. 

A unique set of segments is defined for each EDI 

35 transaction type. These segments represent the mandatory 
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data elements required Tor each functional group in 
addition co any optional or conditional elements 
necessary for implementation of the applications. New 
segment definitions may be added to incorporate 

> additional data elements . All interface file segments 
records must be built by the application in the sequence 
specified for a particular transaction type. 

Data elements within a segment have fixed lengths, 
with no delimiters between data elements. Binary data 

0 elements are contained in a separate file whose name is 
contained .in a segment data element. The order in which 
da;: a elements appear in the segment, may not necessarily 

functional group. Ail segment data element pos: t ions are 
5 present in both outbound and inbound transactions. 
Except where noted, all data elements contain data in 
both outbound and inbound transactions. In those cases 
where the length of a data element may be less than the 
fixed length oi: the data element field, the data is left- 
s aligned and the unused bytes must ho padded with ASCII 
blanks . 

An X9.46 loop st rue-: ure may bo represented by a 
single segment or a sequence of segments. Loop 
iterations are specified by repeating the segment or 

j segments for the required number of iterations. The 

nesting sequence of outer and inner loops is as described 
in the ANSI Z9.46 proposed standard specification. Loop- 
structures must be constructed in the order described for 
the transaction type. Subordinate loop sequences must be 

5 completed before the ne.xt higher level loop can be 
repeated . 

A transaction set reference ID 220 is used to 
associate two functional groups. Per example, the 
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which requested the images. The transaction set 
reference ID ot the query request will be inserted in the 
transaction set reference ID of the resulting item views 
transaction to allow the receiving application to 
5 associate the inbound item views transaction with the 
query request transaction that requested the images. 
Since the EDI translator generates the transaction set 
reference ID for ail outbound transactions., the 
transaction set reference ID must be returned to the 

10 application in a status file after the EDI translator 
builds the outbound transaction. 

In a transaction, the application sends an 
outbound query to the EDI translator. After building the 
query request transaction, the EDI translator returns the 

15 transaction set reference ID 22 0 to the application in a 
status file. The receiving ED J translator passes the 
transaction set reference ID ot the query request: 
transaction to the receiving application along with the 
query contents. When the receiving application builds 

20 the item views transaction, .if passes the transaction set 
reference ID of the query request transaction to the EDI 
translate! .. which insert's it into the transaction set 
cross reference ID of the item views transaction. This 
associates the item views transaction with the query 

25 request transaction. When it receives the item views 
transaction, the application which sent the query 
extracts the transaction set: cross reference ID to 
associate the inbound item views transaction with the 
original query request transaction. 

30 The EDI translator maintains two status tiles 

which will be available to the application after every 
outbound call to the EDI translator., one for results of 
outbound query requests and the other for results of 
outbound item vi e w request s . The s ta i: u s f: i 1 es c ont a a.n 
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the call status and the transaction set reference I D of: 
the transactions created by the EDI translator. 

The ED] translator builds a status file with the 
appropriate file name after processing an outbound 
Y> request from the application. The status file is 
available to the application after a return code is 
posted for the call. Once the status tile is read., the 
application must delete the file. The EDI translator may 
not build another status £iie for a given transaction 

10 until the last statu.? file has been erased by the 

application. If the application calls the translator to 
process a transaction without having first erased the 
previous status file for that t transact i cn type, a non- 
zero return code will be posted and the translator will 

IS not accept the call. The content or ttie status file is 
associated with only one call. The EDI translator -nay 
not. append stratus information from separate calls into 
one status file. 

The application initiates outbound communication 

2 0 by making a call to the EDI translator. The EDI 
translator responds with a return code of. zero to 
indicate a successful operation or a non-sere return code 
to indicate an error. The call structure and the rerun:, 
codes are defined tor the EDI translator. Only one 

25 interface file rcay he passed to the EDI translator .tor- 
each call, and only one transaction rr;ay be presented in 
each outbound interface file. 

To send an outbound transaction froro the 
application to the EDI translator, the application, 

30 creates a lock and an interface file using the 

appropriate file name. The application then places the 
segment information in the interlace file and turns off. 
the lock . The application passes the file name to the 
EDI translator via a call. The EDI translator locks the 

35 file specified in the call and receives tne c 
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transaction. Jf the call is successful the ED X 
translator erases the interface file, turns off the lock,, 
and posts a return code of zero to the application. If 
the call is unsuccessful the EDI translator turns off the 
lock, but will not erase the interface file and a non- 
zero return code is be posted to the application. 
F.?nal.ly, the application erases the interface file. 

To receive inbound core-nun i cat ions fro-vi the EDI 
translator., the application polls the system for the 
existence of unlocked inbound interface files. The 
inbound interface file may contain one or more 
transactions. The receiving application processes some 
or ail of the transactions received in the inbound file. 
Transactions not processed by the application must be 
returned to the EDI translator a.? described below. 

inbound transactions are sent from the EDI 
translator to the application. If the appropriate 
inbound interface file does not exist... the SDI translator 
will create a lock and a file w.ith the appropriate file 
name. It the file already exists, the EDI translator 
will place a lock, on the file. The SDI translator will 
place the inbound transaction at the beginning of the 
interface file if the file is new or append the 
transaction to the existing content if the file already 
exists-. The SDI translator then unlocks the interface 
file. When the application detects the file by polling, 
it places a lock on it. 

An application may process one or more 
transactions in the file. If the application processes 
the entire content of the inbound interface file it must 
erase tne file and remove the lock. If the application 
does not. process ail of the transactions in the inbound 
transaction it trsust delete ail segment associated with 
the transactions it processed. The lock will then be 
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rerriov&d trosr. the interlace file to release it bach r.c the 
EDI transistor. 

Other embodiments are within she scope of the 
t o 1 1 aw i ng c .1 a i ms . 

What is? claimed is; 
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creating a first electronic representation of 
binary content of an image of" a financial .Instrument in 
accordance with a predefined data structure, 

processing the first electronic representation to 
generate a digital delivery format complying with a 
common ok; livery protocol, and 

delivering the digital delivery format over an 
electronic data communication network. 



': claim l. farther comprising 
ting the digital delivery format to 
electronic represent at. ion comply inq with a second 
predefined data structure protioeoi . 



3. The method cA claim 2 in which the predefined 
15 data structures are the same. 



5. The method of. claim 4 in which the 
comprises displaying an image of the financial 



6. The method of claim 4 in which the processing 
comprises printing an image of the financial instrument . 

7. The method of claim 1 in which the first 
electronic representation is created at a first financial 

25 institution and the digital delivery format .is delivered 
to a second financial institution or merchant. 



8. The method c 
protocol comprises a protocol recognized In 
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firs-: financial institution and the second financial 
institution. 



9. The method of claim '"' in which the first 
(ifmed ds-:a structure comprises « proprietary data 
structure on the first financial institution. 



lb. The method of claim I in which the ti-c&i 
ei-ictronic representation comprises «n linacje of the 



11. The method of clad it. I in which the first 
10 eiecu'onjc representor 1012 comprises a digii.Vi eodeiine 
representation of the financial ms-: r amen t . 



The method of claim I in which the financial 




15. The method of claiir. i iurchcr comprising 
storir.q the first electronic representation for 
lent retrieval upon a 



l' 7 . The method of claim 16 in which the request, 
is delivered eiectron.toal.iy to the first financial 
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institution from a second financial institution and the 
digital delivery format: is delivered to the second 
f i nsnc i a I ins t i t at i on . 



IS. The method of" claim 1 6 further eorr.pri sine; 
processing the first electronic representation at 
the first .financial inst i tin: ion . 

19. The me Shod of claim 16 m which the 
processing comprises displaying an image of the financial 
instrument . 



ocessing comprises printing an image of the 



21, The method of claim 15 in which the request 
i s generated automa tically . 



22. The method of. claim 15 further comprising 
assigning the first electronic representation a 
idenci i xcat ion index . 



23. The met nod of claim 22 in which the request 
comprises the identification index. 

2<t . The method of claim I further comprising 
encrypting the digital delivery format for secure 
delivery over the electronic data communicar. i on network. 

2 5 . Appa ra t us comp r 3 s i ng 

a capture device for obtaining a first electronic 
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a ^translator for converging the first. electronic 
representation into a digital delivery format complying 
with a second protocol , and 

means for delivering the digital delivery format 
over an electronic data communication network. 



2" ; . The apparatus of claim 25 in which the first 
10 electronic representation comprises a diqita.: code! me 
of the financial instrument. . 



2S, The apper-tue of. claim 25 .in which the 



2'ii , The apparatus? of claim 25 in which the 
15 financial instrument comprises a credit card slip. 



30. The apparatus of claim 25 an which the second 
protocol is a commonly accepted protocol . 



31. The apparatus of 
capture device comprises a so 



2 5 in which the 



:us of claim 25 further comprising 
for storing the first electronic 



33. The apparatus of claim 32 *urtn«r comprising 
a workstation for processing the stored first 
2 5 electronic 
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3 4. The apparatus oL claim 33 in will ch the 
processing comprises displaying an image or the- f inane i,-: 
instrument . 

AS ■ The apparatus of claim 3 3 m which the 
5 processing comprises printing an xvcisqe ct th* f inancial 
instruraent . 

3 6. The apparatus of. claim 32 in winch the; 
workstation comprises an interactive display of the firs 
e 1 ect roni c r<spre ?ent. at i on . 

10 37, The apparatus of claim in which the 

t ra n s 1 a t o r c omp r i s e a o HPT t ran s .1 a t o r . 

3S. Apparatus comprising 

means for electronically receiving a digital 
del 3 very format of a financial instrument: cotrplving with 
1 5 a 1 1 r s t p rot. oco .1 , and 

a translator for converting the digital delivery 
format into an electronic represent at ion complying wi th 
second protocol . 

39. The apparatus of cj 3 8 m which the 
20 electronic representation comprises an image of: the 

financial instrument . 

40. The apparatus of claim 3 3 in which the 
electronic representation comprises a digital code! ine 
representation of: uv= financial instrument. 

25 41. The apparatus of. claim 3? :.n which the 

financial instrument comprises a check. 
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41:. The apparatus of claim 3 8 in which the 
.al instrument comprises a credit card slip. 



4<. The apparatus of claim 38 in which the- firs;: 
pro-ioc-.:;'! comprises a commonly accepted protoco.1 , 



<S 4<i . Th.e 

l r ■ >. a i a t o r comp r 



us of claim IB .in which the. 
EDI 



4b. The apparatus of cla.iT: further comprising 
tion for 



o£ claim 45 in which 
displaying an image of u-£ 



4", The apparatus of clasrn 45 in which the 
processti rtq comprises printing an imags f. the i 



v.'orksr. at -.on 
elect ronic 



at: us of clain -IT- in which the 
an .interactive display of the first 
tion. 



49. A method for ti 
30 check clearance: system cctnp- 

capturing an electronic imane of the paper check 
at. a first oan'-ting institution, the e.i ectron.i c image 
complying with a first protocol, 

converting the electronic image to a digital 
?6 delivery Eozioar compl ying with a common second protocol, 

sending the digital delivery fornur: digitally frorrs 
the first banking institution to a second banking 
institution, 
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at the second banking convert in 
delivery derma t to an electronic image 
third protocol, and 

processing the electronic image, 
third protocol for clearance purpose?.;. 

50. The method of claim -19 j.n which the digital 
delivery format comprises a secure format created by 
encryption . 

51. A method for use by financial institutions 
with respect to financial instruments comprising 

s t o r i ng , & t d i f f e r e nt. f i n a nc r a i xnc t i t. u ■: i on s , 
electronic images of paper financial instruments 
presented to the respective institutions, the storinc? at 
different financial institution;;; being done in accordance 
with different protocols, 

at each of the financial institutions, accepting 
electronic requests tor copies of. specified ones of the 
electronic images stored at the respective financial 
institutions, the request:-;; being sent by any of the 
financial institutions via a coaiinon communication 
network , and 

at each of the financial institutions, rsspondmq 
to electronic requests by converting the requested 
electronic images r.o a common protocol arid returnina the 
images an digital form to the requesting financial 
institution. 

£2. The method of claim 51 in which the 
electronic requests are generated automatically. 

S3, The method of claim 1 further comprising 
automatically processing the binary content of the imaqe 
to verify the authenticity of the item. 



g the digital 
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55. The method of claim 5:? in which che 

5 processing include? using cryptography for de t e rrrd n i ng 
authenticity. 

56 . The method of claim 1 further comprising 
automatical ly processing the binary content to identify 
handw r i c ten informa t ion - 



.10 ?>'?. The method of claim S3 farther comprising 

marking the financial inst rurn«nt with an authenticity 
flag and automatically processing the binary con cent co 
identify che authenticity flag. 

SB. The method of claim 1 further comprising 
15 automatically processing the binary content to detertr,in< 
if t.he financial instrument had been altered without 
authors, aat ion . 



59. A method comprising 

storing binary content of images of. financial 
2 0 instruments in accordance with a predefined data 

structure and information uniquely identifying each of 

encapsulating the binary content of each of the 
images in a delivery package that complies with a commoi 
25 protocol , and 

in response to a request for linages having 
specified identifying information, sending packages 
containing the binary contents of the images an digital 
form . 
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60. The method of claim 1 in which the process inq 
of che first electronic represent a i: ion includes selectmq 
only snippets of the binary content for inclusion in the 
digital delivery format. 
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